Skip to content

Fix #11481: Count signature names as consistent if one of them is a wildcard #12033

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Fix #11481: Count signature names as consistent if one of them is a wildcard #12033

wants to merge 1 commit into from

Conversation

anatoliykmetyuk
Copy link
Contributor

@anatoliykmetyuk anatoliykmetyuk commented Apr 8, 2021 •
edited
Loading

If the i11481a.scala test ("Bad" example) is modified to the following ("Good" example), it works:

case class Baz[F](f: {def f(x: F): Object})

In the Bad case, at some point, the typer tries to check if the following subtyping holds:

(Baz.this.f : Object{f(x: F[Int]): Object}) <: Object{f(x: <?>): Object}

It fails in the Bad case. In the Good case, it checks for:

(Baz.this.f : Object{f(x: F): Object}) <:< Object{f(x: <?>): Object}

And succeeds.

The reason for failure can be traced to here:

https://github.com/lampepfl/dotty/blob/a0707985bfdb40a29e79b1f034e6caa0570374f8/compiler/src/dotty/tools/dotc/core/TypeComparer.scala#L684

Typer checks the signatures of the involved methods. The following is the debug of the variables involved in that line:

Bad
001 tp1 = (x: F[Int]): Object
002 tp1.signature = Signature(List(java.lang.Object),java.lang.Object)
003 tp2 = (x: <?>): Object
004 tp2.signature = Signature(List(_),java.lang.Object)
005 tp1.signature consistentParams tp2.signature = false

Good
001 tp1 = (x: F): Object
002 tp1.signature = Signature(List(java.lang.Object),java.lang.Object)
003 tp2 = (x: <?>): Object
004 tp2.signature = Signature(List(java.lang.Object),java.lang.Object)
005 tp1.signature consistentParams tp2.signature = true

Note 004 line for each output, the signatures for Bad and Good cases vary: it is Object for Good case but wildcard for bad case.

It seems this is because for the Good case, the wildcard in question has bounds which is not the case for the Bad case:

Good
001 tp2 = MethodType(List(x), List(WildcardType(TypeBounds(TypeRef(ThisType(TypeRef(NoPrefix,module class scala)),class Nothing),TypeRef(ThisType(TypeRef(NoPrefix,module class scala)),class Any)))), TypeRef(TermRef(ThisType(TypeRef(NoPrefix,module class java)),object lang),class Object))

Bad
001 tp2 = MethodType(List(x), List(WildcardType), TypeRef(TermRef(ThisType(TypeRef(NoPrefix,module class java)),object lang),class Object))

It seems having bounds makes the signatures assume the form of those bounds whereas not having bounds means leaving a wildcard as a wildcard:

https://github.com/lampepfl/dotty/blob/a0707985bfdb40a29e79b1f034e6caa0570374f8/compiler/src/dotty/tools/dotc/core/TypeErasure.scala#L824-L827

In this PR I chose to simply treat the signatures as consistent if the names being compared involve a wildcard. I am not sure if this is the right fix or a more elaborate fix involving bounds should be devised.

@anatoliykmetyuk anatoliykmetyuk requested a review from odersky April 8, 2021 17:43
odersky
odersky reviewed Apr 10, 2021
View reviewed changes
Copy link
Contributor

@odersky odersky left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit nervous since this is very low-level fundamental code. Can we break something else by making the change?

The issue is about polymorphic function types, which is really the domain of @smarter so he should weigh in. If we can show that tpnme.WILDCARD is only used for polymorphic function types and that including it in the test solves the problem, this is the right fix. If not, we need something else.

@odersky odersky requested a review from smarter April 10, 2021 16:58
@smarter
Copy link
Member

smarter commented Apr 10, 2021

Thanks for the detailed description. I'll take a closer look next week but intuitively I'd expect all wildcards (bounded or not bounded) to be represented in signatures with tpnme.Uninstantiated, because they can match multiple different types (and implementing that change shouldn't affect tasty compatibility since wildcard types are never stored in trees).

@anatoliykmetyuk
Copy link
Contributor Author

anatoliykmetyuk commented Apr 12, 2021 •
edited
Loading

Note that this is not only about polymorphic functions. In the a test, the example only involves structural types and has the same problem.

@smarter
Copy link
Member

smarter commented Apr 27, 2021

Alternative fix implementing the suggestion I made above: #12240

@anatoliykmetyuk anatoliykmetyuk deleted the fix-11481 branch April 28, 2021 09:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@odersky odersky odersky left review comments

@smarter smarter Awaiting requested review from smarter

Assignees

@smarter smarter

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@anatoliykmetyuk @smarter @odersky